Hi, dedupeStreamingMessageIds keeps only the last occurrence of each message.id, which makes parseApiCall/groupIntoTurns use the later streaming update’s timestamp (typically message_stop) as the call timestamp. This can incorrectly include/exclude turns in dateRange filtering and shift day bucketing near midnight because the code explicitly uses the first assistant call timestamp as the cost-incurrence time.

Severity: action required | Category: correctness

How to fix: Preserve first timestamp per id

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

dedupeStreamingMessageIds() keeps the last entry for a given message.id, which changes the assistant call timestamp downstream to the later message_stop timestamp. This conflicts with parseSessionFile date bucketing/filtering logic that uses the first assistant call timestamp as the cost-incurrence timestamp.

Issue Context

The goal (keeping final tool_use blocks and authoritative usage) is correct, but timestamp semantics matter for dateRange filtering and day bucketing.

Fix Focus Areas

• src/parser.ts[122-142]
• src/parser.ts[285-330]

Suggested fix

Update dedupeStreamingMessageIds to keep the last entry’s content/usage, but preserve the earliest timestamp seen for that message.id:

• First pass: track both lastIdxById and firstTimestampById (or earliest timestamp string) for each id.
• Second pass: when you are about to push the kept (last) entry for an id, if firstTimestampById exists and differs from entry.timestamp, push a shallow clone { ...entry, timestamp: firstTimestamp } (avoid mutating input in-place).
• Update/add a unit test to assert that the kept entry retains the first timestamp for bucketing, while still retaining the final tool_use/usage from the last update.

Found by Qodo code review

Good catch on the timestamp semantics.

Pushed 88baed8. dedupeStreamingMessageIds now keeps the last entry's content (tool_use blocks + authoritative usage) but overrides its timestamp with the first entry's value, so downstream date-range bucketing / filtering in parseSessionFile continues to use the cost-incurrence time when the call started.

Tests updated to assert both invariants; added a non-mutation test on the input array.

Full suite: 360 / 360. npx tsc --noEmit clean.

Closing this. The streaming dedup fix itself is solid, but the PR also silently removes flushCodexCache() and flushAntigravityCache() calls from parseProviderSources, which would break cache persistence for codex and antigravity users (every run re-parses everything from scratch). These removals aren't mentioned in the PR description. We'll apply the dedup fix separately. Thanks for identifying the streaming issue though.